Refactor: Centralize signature ordering logic in FLRP transaction builders #7811
+844
−211
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor: Centralize Signature Ordering Logic in FLRP Transaction Builders
Summary
This PR centralizes the signature ordering and AddressMap creation logic in FLRP transaction builders to match avaxp's architecture pattern. This eliminates ~200+ lines of duplicated code across
ImportInPTxBuilder,ImportInCTxBuilder, andExportInPTxBuilder.Problem
FLRP had duplicated signature ordering logic scattered across each builder:
addressesIndex-based credential ordering logicinitBuilder,buildFlareTransaction,createInputs, etc.)AtomicTransactionBuilderSolution
Introduced two centralized helper methods in
AtomicTransactionBuilder:createCredentialForUtxo()- Creates credentials with dynamic ordering based on UTXO address positionscreateAddressMapForUtxo()- Creates AddressMaps matching credential orderAll builders now use these centralized methods, ensuring consistent behavior across all transaction types.
Changes
New Centralized Methods:
AtomicTransactionBuilder.createCredentialForUtxo()- Handles credential creation with UTXO-based orderingAtomicTransactionBuilder.createAddressMapForUtxo()- Handles AddressMap creation matching credential orderRefactored Builders:
ImportInPTxBuilder- UpdatedinitBuilder()andbuildFlareTransaction()to use centralized methodsImportInCTxBuilder- UpdatedinitBuilder()andbuildFlareTransaction()to use centralized methodsExportInPTxBuilder- UpdatedinitBuilder()andbuildFlareTransaction()to use centralized methodsTechnical Details
The signature ordering logic uses
addressesIndexto determine the order of addresses in UTXOs:addressesIndex[bitgoIndex] < addressesIndex[firstIndex]: Bitgo signature comes first (slot 0)This ensures AddressMaps match credential order, preventing signature index mismatches.
Related